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MDA  Architecture  Management  Hub  Strategy 


“ Maritime  Domain  is  all  areas  and  things  of,  on,  under,  relating  to,  ad¬ 
jacent  to,  or  bordering  on  a  sea,  ocean,  or  other  navigable  waterway, 
including  all  maritime-related  activities,  infrastructure,  people,  cargo, 
and  vessels  and  other  conveyances.  ” 

Maritime  Domain  Awareness  (MDA)  is  the  effective  understanding 
of  anything  associated  with  the  maritime  domain  that  could  impact  the 
security,  safety,  economy,  or  environment  of  the  United  States. 

“ Global  Maritime  Community  of  Interest  (GMCOI)  includes,  among 
other  interests,  the  federal,  state,  and  local  departments  and  agencies 
with  responsibilities  in  the  maritime  domain.  Because  certain  risks 
and  interests  are  common  to  government,  business,  and  citizen  alike, 
community  membership  also  includes  public,  private  and  commercial 
stakeholders,  as  well  as  foreign  governments  and  international  stake¬ 
holders.  ” 
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Background 


Information  sharing  is  a  foundational  tenet  of 
Maritime  Domain  Awareness  (MDA).  Current¬ 
ly,  identical  information  is  collected  and  stored 
by  multiple  agencies  and  organizations.  However, 
these  agencies  are  often  unaware  that  similar  in¬ 
formation  is  available  from  other  organizations,  or 
they  are  aware  but  unable  to  share  this  information 
with  one  another  because  information  sharing  stan¬ 
dards,  agreements,  policies,  or  processes  currently 
do  not  exist.  Similarly,  agencies  with  relevant,  re¬ 
lated,  or  complementary  information  are  unable  to 
combine  their  data  to  achieve  greater  levels  of  situ¬ 
ational  awareness. 

MDA  is  being  implemented  within  the  context 
of  national  information  and  data  sharing  guidance. 
This  guidance  includes  Executive  Order  13388  and 
the  National  Strategy  for  Information  Sharing  (ref¬ 
erences  (k)  and  (i)).  The  National  Strategy  for  In¬ 
formation  Sharing,  although  broader  in  scope  than 
just  MDA  and  focused  on  terrorist  information,  es¬ 
tablishes  guiding  principles  and  foundational  ele¬ 
ments  for  information  sharing  on  a  national  level. 
Many  other  policies,  guidance  documents,  strate¬ 
gies,  and  plans  (see  References  section  at  end  of 
document)  help  set  and  shape  the  direction  of  in¬ 
formation  sharing  for  the  Global  Maritime  Com¬ 
munity  of  Interest  (GMCOI)  and  are  discussed 
throughout  this  document.  They  play  a  major  role 
in  establishing  mechanisms  for  collaborating  and 
enabling  an  aligned  transition  to  the  desired  infor¬ 
mation  sharing  state  for  the  GMCOI. 

The  National  Concept  of  Operations  for  Mari¬ 
time  Domain  Awareness  (MDA  CONOPS)  (refer¬ 
ence  (c))  describes  this  desired  state  as  an  environ¬ 
ment  in  which  the  GMCOI  embraces  and  achieves 
the  common  objective  of  obtaining  and  sharing  in¬ 
formation  as  a  mechanism  to  increase  the  safety, 
security,  and  economic  prosperity  in  the  maritime 
domain. 

The  MDA  CONOPS  outlines  how  the  Feder¬ 
al  Government  will  organize  to  achieve  maritime 
domain  awareness.  It  creates  a  federal  interagency 
structure  that  includes  an  MDA  Stakeholder  Board 
to  coordinate  and  align  MDA  policies.  In  addition, 


the  MDA  CONOPS  creates  four  enterprise  hubs. 
Each  of  these  hubs  is  responsible  for  coordinating 
information  sharing  among  the  multiple  agencies 
and  organizations  within  each  MDA  information 
pillar:  vessels,  cargo,  people,  and  infrastructure. 

An  additional  hub,  the  Architecture  Manage¬ 
ment  Hub,  was  established  by  the  MDA  CONOPS 
to  design  and  manage  the  overall  enterprise  ar¬ 
chitecture  needed  to  facilitate  net-centric  sharing 
of  maritime  information  among  the  GMCOI  as 
described  in  the  MDA  CONOPS.  An  enterprise 
architecture  provides  a  clear  and  comprehensive 
picture  of  the  structure  of  an  entity,  whether  an 
organization,  functional  area,  or  mission  area.  It 
provides  those  who  manage,  construct,  and  main¬ 
tain  the  entity  with  a  clear  and  understandable  pic¬ 
ture  of  the  entity’s  uses,  features,  functions,  and 
supporting  systems,  including  relevant  standards. 
The  MDA  enterprise  architecture  will  provide  the 
standards  and  processes  that  will  allow  the  four  en¬ 
terprise  hubs,  and  any  other  maritime  community 
member,  to  share  information  and  services. 

The  MDA  CONOPS  identifies  a  lead  agency  or 
department  for  each  of  the  four  enterprise  hubs  and 
the  Architecture  Management  Hub.  The  Depart¬ 
ment  of  the  Navy  (DON)  is  the  executive  agent  for 
the  Department  of  Defense  for  MDA  and  has  been 
designated  as  the  lead  department  for  the  Architec¬ 
ture  Management  Hub.  The  DON  has  further  del¬ 
egated  this  responsibility  to  the  Department  of  the 
Navy  Chief  Information  Officer  (DON  CIO). 
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Purpose  &  Organization  of  this  Document 


This  document  provides  an  initial  high-level 
plan  for  carrying  out  the  responsibilities  of 
the  national  Maritime  Domain  Awareness 
Architecture  Management  Hub  to  deliver  a  stan¬ 
dards  based  service  oriented  architecture  that  will 
align  MDA  capabilities. 

It  outlines  key  goals  of  the  MDA  Architecture 
Management  Hub  and  how  the  hub  will  build  on  pre¬ 
vious,  current,  and  emerging  information  sharing 
initiatives.  A  discussion  of  necessary  governance 


in  the  context  of  the  MDA  Architecture  Manage¬ 
ment  Hub  follows.  Subsequently,  high-level  strate¬ 
gies  for  the  overall  MDA  enterprise  architecture,  as 
well  as  strategies  for  key  tenets  of  net-centric  infor¬ 
mation  sharing  (data  standards  and  information  as¬ 
surance)  are  included.  Finally,  this  document  will 
address  the  resource  implications  for  development 
and  implementation  of  the  architecture. 
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The  goal  of  the  Architecture  Management 
Hub  is  to  provide  a  blueprint  to  develop  a 
net-centric,  information  sharing  environ¬ 
ment,  in  which  data  from  disparate  sources  and 
security  domains  will  be  discoverable,  accessible, 
understandable,  fused,  and  usable,  with  appropriate 
information  assurance,  to  enable  user  defined  and 
common  operational  pictures.  This  blueprint  will 
guide  departments  and  agencies  in  their  develop¬ 
ment  of  capabilities  to  enable  MDA,  and  facilitate 
the  sharing  of  maritime  information  with  state,  lo¬ 
cal,  and  tribal  governments,  international  partners, 
and  the  private  sector. 

The  principal  characteristic  of  the  MDA  enterprise 
architecture  is  that  it  will  be  actionable.  As  an 
actionable  architecture,  it  will: 

•  Inform  relevant  investment  decisions. 

•  Translate  stakeholders’  capability  needs  into 
requirements  that  can  be  engineered. 

•  Drive  the  design  of  services,  applications,  and 
systems  based  on  those  requirements. 

•  Support  the  selection  of  technology  that  fulfills 
capability  needs. 

•  Provide  a  formal  basis  for  validating  solutions 


against  the  originally  identified  capability 
needs. 


Vessel  Positions  in  the  Mediterranean  Sea 


Building  on  Current  Initiatives 


<  /*  ifKj  ' 


Interagency  involvement  in  the  development  of 
the  architecture  will  be  critical  to  obtaining  sup¬ 
port  for,  and  use  of,  the  architecture.  The  author¬ 
ity  to  direct  MDA  stakeholders  to  publish  data  and 
make  services  available  resides  within  the  compo¬ 
nents  and  agencies  themselves.  As  a  result,  artic¬ 
ulating  the  benefits  of  a  networked,  Service  Ori¬ 
ented  Architecture  (SOA)  and  demonstrating  early 
accomplishments  will  be  critical  to  the  long  term 
success  of  the  effort  (SOA  is  discussed  in  more  de¬ 
tail  on  page  10).  Development  of  the  architecture 
will  proceed  in  an  incremental  fashion  with  new 
users  and  services  added  over  time,  including  those 
from  state,  local,  and  tribal  governments,  the  pri¬ 


vate  sector,  and  international  partners. 

The  efforts  of  the  Architecture  Management 
Hub  will  build  on  earlier  accomplishments  of  the 
MDA  Implementation  Team  and  its  associated 
work  groups.  In  2007  the  MDA  Implementation 
Team  established  an  on-going  national  MDA  or¬ 
ganizational  structure  through  the  MDA  CON- 
OPS.  The  MDA  Implementation  Team  also  used 
a  four-step  capability-based  assessment  process  to 
document  initial  requirements  and  existing  capa¬ 
bility  gaps  for  MDA.  These  documents  include: 
the  Interagency  Requirements  Analysis  (reference 
(e)),  Interagency  Needs  Analysis  (reference  (f)),  In¬ 
teragency  Capabilities  Document  (reference  (g)), 
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and  Interagency  Investment  Strategy  (reference 
(d)).  These  documents  identify  15  critical  capa¬ 
bility  gaps  and  the  tasks  required  to  fill  them.  Of 
these  tasks,  the  following  three  relate  to  net-centric 
information-sharing: 

•  Enable  network  access  to  all  designated  nodes 
across  the  GMCOI. 

•  Implement  Information  Assurance  (IA)  and 
Cross  Domain  Security  procedures  across  the 
GMCOI. 

•  Establish  National  MDA  data  standards  across 
the  GMCOI. 

These  tasks,  along  with  the  recommended  solu¬ 
tions,  will  provide  the  initial  priorities  for  the  MDA 
enterprise  architecture. 

The  MDA  Interagency  Core  Architecture  Doc¬ 
ument  (IACA)  (reference  (h)),  developed  as  part  of 
this  work,  provided  a  preliminary  look  at  both  as-is 
and  to-be  elements  of  an  interagency  MDA  enter¬ 
prise  architecture.  The  IACA  development  process 
focused  on  identifying  existing,  or  as-is  interagen¬ 
cy  relationships  and  current  MDA  capabilities  and 
gaps.  This  development  process  also  identified  pos¬ 
sible  courses  of  action  for  agency  and  departmental 
decision  makers  to  close  current  capability  gaps  as 
part  of  the  to-be  architecture  efforts. 

Within  the  MDA  community,  other  initiatives 
are  underway  to  develop  net-centric  capabilities. 
Ground  breaking  efforts,  such  as  the  MDA  Data 
Sharing  Community  of  Interest  (DS  COI),  have  led 
the  way  in  developing  SOA  capabilities  within  the 
MDA  community.  The  goal  of  these  efforts  has 
been  to  make  maritime  data  discoverable  (easy  to 
find),  accessible,  understandable,  and  usable  for  a 
variety  of  users,  including  those  who  previously 
could  not  obtain  and  make  use  of  the  data.  The 
MDA  DS  COI  has  made  data  and  services  avail¬ 
able  for  use  by  other  applications  using  DoD’s  Net- 
Centric  Enterprise  Services  and  has  provided  an 
interface  for  the  unanticipated  user  via  a  Google 
Maps  Mediation  Service. 

The  Office  of  Naval  Intelligence  is  using  a 
phased  approach  to  transition  and  transform  the 
Integrated  Maritime  Intelligence  Architecture 
(IMA)  to  an  enterprise  architecture  that  optimizes 
functional  and  technological  capabilities  to  enable 
seamless  and  scalable  access  to  an  integrated  glob¬ 


al  maritime  intelligence  domain.  The  IMA  will  im¬ 
plement  a  SOA  approach  “for  organizing  and  (re) 
using  enterprise  services  to  support  interoperabil¬ 
ity  between  National  Maritime  Intelligence  Center 
enterprise  data  assets  and  applications,  and  estab¬ 
lished  data  sharing  and  interoperability  environ¬ 
ments  with  DoD,  federal,  and  Coalition  partners” 
(reference  u). 
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National  MDA  Interagency  National  Concept  of 

Investment  Strategy  &  Operations  for  Maritime 

Supporting  Documents  Domain  Awareness 


MDA  Implementation  Team  Family  of  Documents 

The  National  Oceanographic  and  Atmospher¬ 
ic  Administration  (NOAA)  is  leading  an  effort  to 
develop  a  coordinated  national  network  of  ocean, 
coastal,  and  Great  Lakes  observation  capabilities 
known  as  the  Integrated  Ocean  Observing  System 
(IOOS).  IOOS  represents  a  national  partnership 
of  17  federal  agencies  and  11  regional  associations 
sharing  responsibility  for  the  design  and  operation 
of  the  system.  Once  completed,  IOOS  will  integrate 
oceanographic  observation  systems  from  through¬ 
out  the  federal,  state,  and  local  governments,  as 
well  as  the  scientific  and  academic  communities. 
IOOS  has  already  made  tremendous  strides  shar¬ 
ing  maritime  information  across  widely  dispersed 
agencies  and  organizations  that  will  greatly  benefit 
the  Architecture  Management  Hub  effort. 

Of  particular  note  is  the  interagency  work  being 
accomplished  for  the  Federal  Information  Sharing 
Environment  (ISE).  Although  the  ISE  is  primarily 
concerned  with  sharing  terrorist  related  informa¬ 
tion,  their  effort,  “...aligns  and  leverages  existing 
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information  sharing  policies,  business  processes, 
technologies,  systems,  and  promotes  a  culture  of 
information  sharing  through  increased  collabora¬ 
tion”  (reference  (J)).  These  same  areas  must  be 
aligned  to  form  a  cohesive  enterprise  architecture 
for  MDA. 

The  Architecture  Management  Hub  will  build 
on  the  successes  of  these  efforts,  while  encourag¬ 
ing  other  successful  MDA  efforts,  including  nu¬ 
merous  international  efforts,  to  integrate  into  the 
net-centric  environment.  Many  current  efforts  pro¬ 
vide  a  tremendous  capability,  but  exchange  infor¬ 
mation  in  a  point-to-point  manner  and  do  not  ben¬ 
efit  the  broader  maritime  community.  Once  these 
capabilities  are  migrated  to  a  SOA,  their  data  and 
services  can  be  re-used  and  made  available  to  any 
authorized  user  as  necessary  to  enable  MDA. 

These  various  efforts  are  being  developed  and 
fielded  without  a  unifying  architecture  to  form  a 
cohesive  information  sharing  environment  that  can 


benefit  all  partners  in  the  GMCOI.  The  Architec¬ 
ture  Management  Hub  will  align  these  and  other 
efforts,  identify  and  catalogue  relevant  associated 
systems,  and  leverage  the  standards  and  process¬ 
es  that  already  exist.  This  will  help  to  establish  a 
comprehensive  current  state  architecture  MDA  re¬ 
lated  efforts.  Based  on  this  work,  transition  and 
implementation  plans  will  be  developed  to  achieve 
the  desired  end-state  MDA  enterprise  architecture. 

As  the  Architecture  Management  Hub  matures, 
metrics  and  measures  of  effectiveness  will  be  de¬ 
veloped  to  ensure  sufficient  progress  is  being  made 
toward  its  objectives.  Various  existing  operational 
exercises  will  be  used  to  evaluate  the  ability  of  us¬ 
ers  to  exchange  information.  A  concerted  outreach 
effort  will  also  be  undertaken  to  inform  and  edu¬ 
cate  potential  users  on  the  processes  developed  and 
how  to  participate  in  the  network. 
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Governance 


As  the  lead  for  the  Architecture  Manage¬ 
ment  Hub,  the  DON  CIO  will  work  with 
the  existing  governance  structure  estab¬ 
lished  by  the  MDA  CONOPS,  and  will  leverage 
other  governance  bodies,  such  as  the  Federal  CIO 
Council.  In  this  role,  the  DON  CIO  will  focus  on 
coordinating  the  MDA  enterprise  architecture  ef¬ 
forts  and  developing  appropriate  policies,  proce¬ 
dures,  and  standards. 

Federal  interagency  MDA  efforts  are  coordi¬ 
nated  by  the  MDA  Stakeholder  Board,  which  is 
co-chaired  by  the  Director,  Global  Maritime  and 
Air  Intelligence  Integration  (GMAII)  and  Director, 
Global  Maritime  Situation  Awareness  (GMSA). 
The  Stakeholder  Board  is  a  coordinating  body 
under  the  Maritime  Security  Policy  Coordina¬ 
tion  Committee,  and  is  responsible  for  MDA  pol¬ 
icy  alignment,  synergy,  and  issue  resolution.  The 
MDA  Stakeholder  Board  will  provide  executive 
oversight  of  the  Architecture  Management  Hub, 
and  the  four  enterprise  hubs  (Vessel,  Cargo,  Peo¬ 
ple,  and  Infrastructure).  The  Architecture  Man¬ 
agement  Hub  will  work  closely  with  the  Infor¬ 
mation  Sharing  Sub-Committee  (ISSC),  which  is 
the  executive  management  and  advisory  body  for 
maritime  domain-related  information  sharing  and 
technology  issues. 

These  governance  structures  will  be  leveraged 


to  govern  the  necessary  processes  and  service  level 
agreements  requisite  for  efficient,  effective  opera¬ 
tion  of  an  MDA  enterprise  architecture.  In  addition, 
the  Architecture  Hub  will  coordinate  with  the  Fed¬ 
eral  CIO  Council  to  ensure  that  the  relevant  infor¬ 
mation  technology  activities  within  the  individual 
agencies  are  aligned  to  achieve  MDA  objectives. 

The  Architecture  Management  Hub,  working 
with  the  ISSC,  will  identify  policy  barriers  as  well 
as  cultural,  procedural,  and  technological  barri¬ 
ers  to  information  sharing.  Barriers  include  issues 
such  as  the  lack  of  interagency  coordination/align¬ 
ment  of  information  sharing  policies,  and  a  reluc¬ 
tance  by  some  data  providers  to  provide  detailed 
information. 

To  effectively  execute  the  roles  and  responsi¬ 
bilities  of  the  Architecture  Management  Hub,  the 
DON  CIO  will  establish  focus  teams  to  concentrate 
on  key  aspects  of  the  MDA  enterprise  architecture. 
Focus  team  leads  will  be  designated  by  the  DON 
CIO  and  membership  will  be  composed  of  repre¬ 
sentatives  from  departments,  agencies,  and  organi¬ 
zations  with  membership  on  the  MDA  Stakeholder 
Board.  Focus  team  membership  will  eventually  be 
expanded  to  include  representatives  from  state,  lo¬ 
cal,  and  tribal  governments,  international  partners, 
and  the  private  sector.  Active  participation  by  indi¬ 
viduals  with  knowledge  of  information  sharing  ef- 
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forts  within  their  own  agency  and  the  expertise  to 
effectively  assist  the  focus  team  on  its  assigned  task 
is  critical.  Initial  focus  teams  will  include:  Process, 
Standards,  Technical,  and  Information  Assurance. 

The  Process  Focus  Team  will  document  the 
MDA  operational  processes  described  in  the  MDA 
CONOPS  and  other  documentation.  They  will  also 
develop  standard,  non-technical  processes  and  pro¬ 
cedures  for  publishing  and  subscribing  information 
to  and  from  the  network. 

The  Standards  Focus  Team  will  develop  those 
standards  (schema/vocabulary,  metadata,  etc.)  that 
will  allow  users  to  publish  data  to  the  network  and 
make  it  available  to  other  users  (subscribers).  These 
standards  will  incorporate  appropriate  existing  and 
emergent  standards  (e.g.,  UCore,  NIEM,  etc.)  or 
procedures  for  mediation  as  necessary. 

The  Technology  Focus  Team  will  identify  and 
recommend  technical  solutions  to  enable  net-cen¬ 
tric  information  sharing  within  the  GMCOI. 


The  Information  Assurance  Focus  Team  will 
develop  methods  for  protecting  information  pub¬ 
lished  to  the  network,  including  methods  to  ensure 
only  authorized  users  have  access  to  information 
(confidentiality),  information  cannot  be  manipu¬ 
lated  without  authority  (integrity),  only  authorized 
information  is  published  to  the  network  (authen¬ 
ticity),  and  information  is  available  when  needed 
(availability). 

Each  focus  team  will  in  effect  be  developing 
a  part  of  the  overall  MDA  enterprise  architecture. 
To  ensure  synthesis  of  these  parts  and  create  an  in¬ 
tegrated,  cohesive,  and  actionable  enterprise  archi¬ 
tecture,  an  Architecture  Coordination  Board  will 
be  established.  This  board  will  be  responsible  for 
developing  and  recommending  an  MDA  enterprise 
architecture  description  from  the  recommendations 
of  the  focus  teams. 
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Iterative  Approach 


An  iterative  approach  will  be  used  to  design 
the  MDA  enterprise  architecture.  In  this 
way  users  of  the  architecture  can  realize 
early  benefits  during  the  design,  and  continue  to 
see  increased  utility  over  time.  Each  of  the  Archi¬ 
tecture  Management  Hub  focus  teams,  guided  by 
the  Architecture  Coordination  Board,  will  explore 
topics  within  its  scope,  prioritize  and  select  issues 
to  address,  work  to  resolve  those  issues,  and  evalu¬ 
ate  the  results  before  moving  on.  Focus  teams  will 
work  in  parallel  on  complementary  issues  where 
appropriate. 


Steps  in  the  Iterative  Process 


Discovery 


Discovery  of  Ongoing  Relevant  Efforts 

The  first  step  in  the  process  will  be  a  discov¬ 
ery  phase  in  which  the  focus  team  works  to  under¬ 
stand  relevant  efforts  already  underway.  Within 
this  phase,  the  focus  team  will  examine  various  as¬ 
pects  of  these  efforts  including  the  scope,  purpose, 
intended  users,  organizational  roles  and  relation¬ 
ships,  environments,  and  types  of  data /  informa¬ 
tion  to  be  exchanged  as  applicable.  In  addition,  the 
focus  teams  will  need  to  review  the  level  of  effort, 
extent  of  capabilities,  status  of  deliverables,  and 
schedule.  To  some  extent,  initial  discovery  of  rel¬ 
evant  efforts  has  already  been  ongoing. 


Prioritization 

After  building  an  understanding  of  the  other 
relevant  efforts,  each  focus  team  will  prioritize  the 
challenges  within  its  scope  based  on  gap  analy¬ 


sis  and  input  from  the  enterprise  hubs.  The  focus 
teams  will  develop  a  prioritized  list  of  actionable 
efforts  to  choose  from,  including  potential  courses 
of  action. 

Selection 

Once  a  prioritized  list  is  developed  an  issue  will 
be  chosen  for  the  focus  team  to  resolve.  Guided  by 
the  MDA  Stakeholder  Board,  each  focus  team  will 
select  the  best  option  to  pursue  for  its  initial  work 
from  the  prioritized  list. 

Execution 

Based  on  the  selection  decision,  each  focus 
team  will  carry  out  its  work  to  execute  the  selected 
effort.  Ideally  each  focus  team  will  work  on  one 
issue  at  a  time  in  a  logical  sequence,  but  parallel 
efforts  may  be  necessary. 

Evaluation 

Once  the  initial  effort  is  completed,  each  focus 
team  will  evaluate  the  results,  and  with  the  assis¬ 
tance  of  the  Architecture  Coordination  Board,  in¬ 
corporate  them  into  the  architecture.  Following 
this,  the  focus  team  will  update  its  gap  analysis  and 
plan  for  the  next  iteration.  In  addition  the  focus 
team  will  develop  a  sustainment  plan  to  ensure  the 
longevity  of  the  solution  that  was  developed. 
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Architectural  Approach 


/ 


The  principal  characteristic  of  the  MDA  enter¬ 
prise  architecture  is  that  it  will  be  actionable.  It 
will  be  developed  and  delivered  as  three  principal 
products: 

•  An  As-Is  Architecture  Description  describing 
the  architecture  of  operations  and  resources 
that  compose  the  current  state  of  the  MDA  en¬ 
terprise  architecture. 

•  A  To-Be  Architecture  Description  describing 
the  architecture  of  operations  and  resources 
that  will  compose  the  desired  state  of  the  MDA 
enterprise  architecture. 

•  An  Architecture  Migration  and  Implementation 
Plan  describing  the  capability  gaps  between  the 
current  (as-is)  and  desired  states  (to-be)  of  the 
MDA  enterprise  architecture  as  well  as  a  plan 
for  migrating  existing  resources  and  for  devel¬ 
oping  new  resources  in  response. 

The  as-is  and  to-be  architecture  descriptions 
will  be  composed  of  variations  of  four  primary 
models: 

•  An  Operational  Model  focused  on  describing 
operational  nodes  and  processes  to  share  infor¬ 
mation  within  the  GMCOI. 

•  An  Information  Model  focused  on  enumerating 
and  classifying  the  information  exchanges  with 
and  within  the  GMCOI. 

•  An  Interoperability  Model  focused  on  describ¬ 
ing  standards  for  the  connection  and  exchange 
of  information  between  information  services. 

•  A  Services  Model  focused  on  describing  and 
classifying  the  information  services  necessary 
to  facilitate  the  information  exchanges. 
Although  each  of  the  Architecture  Manage¬ 
ment  Hub  focus  teams  will  be  exploring  numerous 
aspects  of  their  respective  subject  area  and  produc¬ 
ing  a  variety  of  architectural  and  programmatic  in¬ 
sights,  their  collective  products  will  be  integrated 
by  the  Architecture  Coordination  Board  to  form 
the  four  primary  architectural  models  described  in 
this  section. 

Operational  Model.  Preparatory  to  understand¬ 
ing  the  information  exchanges  and  related  services 
that  describe  the  provisioning  of  capabilities  for 


MDA  information  sharing,  it  is  necessary  to  un¬ 
derstand  the  larger  operational  context  for  such 
capabilities.  This  is  accomplished  by  developing 
an  operational  model  to  describe  operational  pro¬ 
cesses  and  associated  nodes  for  sharing  informa¬ 
tion  within  the  GMCOI. 

The  Operational  Model  will  focus  on  opera¬ 
tional  processes  that  involve  data  and  facilitate  in¬ 
formation  sharing.  The  MDA  CONOPS  provides 
an  initial  high  level  categorization  of  these  opera¬ 
tional  processes  as:  Monitor,  Collect,  Fuse,  Ana¬ 
lyze  and  Disseminate.  MDA  stakeholder  segment 
architectures  (as  available)  can  be  aligned  to  these 
operational  processes  to  build  an  integrated  opera¬ 
tional  model  for  MDA. 

Information  Model.  The  key  to  developing  an 
actionable  MDA  enterprise  architecture  is  a  com¬ 
plete  and  correct  understanding  of  the  information 
necessary  to  support  the  operations  and  processes 
described  in  the  MDA  CONOPS.  This  is  accom¬ 
plished  by  developing  an  information  model  that 
enumerates  and  classifies  the  information  exchang¬ 
es  with  and  within  the  GMCOI. 

This  will  include: 

•  Planned  exchanges  between  MDA  information 
pillars,  i.e.  vessels,  cargo,  people,  and  infra¬ 
structure  pillars. 

•  Unplanned  or  unanticipated  exchanges  between 
MDA  information  pillars. 

•  Planned  and  unplanned  exchanges  between 
MDA  information  pillars  and  external  entities, 
e.g.  non-GMCOI  mission  area  organizations. 
The  resulting  understanding  provides  the  foun¬ 
dation  for  all  other  MDA  information  sharing  ar¬ 
chitecture  development. 

Interoperability  Model.  Architectural  styles, 
such  as  Service-Oriented  Architecture  (SOA),  de¬ 
pend  on  the  use  of  standard  protocols  to  enforce  the 
principles,  practices,  and  patterns  composing  the 
style.  In  the  case  of  SOA,  these  protocols  standard¬ 
ize  the  way  information  services  connect  and  ex¬ 
change  information  via  service  interfaces.  The  use 
of  such  protocols  ensures  interoperability  as  solu¬ 
tion  elements  are  developed  and  deployed  to  create 
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the  MDA  enterprise  architecture.  This  is  accom¬ 
plished  by  developing  an  interoperability  model  fo¬ 
cused  on  describing  standards  for  the  connection 
and  exchange  of  information  between  information 
services. 

Services  Model.  The  information  exchanges 
described  earlier  can  be  viewed  as  the  provisioning 
of  capabilities  among  and  by  the  entities  compos¬ 
ing  the  GMCOI.  Best  practices  in  architecture  dic¬ 
tate  the  use  of  a  service-oriented  model  to  describe 
this  provisioning  of  capabilities.  In  other  words, 
emphasis  is  upon  services  as  the  providers  of  ca¬ 
pabilities  to  consumers.  This  is  accomplished  by 
developing  a  services  model  focused  on  describing 
and  classifying  the  information  services  necessary 
to  facilitate  the  information  exchanges.  This  is  in 
contrast  to  traditional  approaches  to  information 
systems  architecture  that  focus  on  the  underlying 
hardware  and  software  as  the  solution  to  capability 
need.  The  development  of  a  services  model  im¬ 
plies  the  use  of  an  SOA  architectural  style. 

The  following  diagram  provides  a  high  lev¬ 
el  outline  of  these  four  models  as  milestones  to 
achieve  the  as-is  architecture  and  an  initial  version 
of  the  to-be  architecture 


There  are  two  key  aspects  that  must  be  con¬ 
sidered  in  developing  the  above  models.  The  first 
is  the  employment  of  SOA  principles,  practices, 
and  patterns.  The  second  is  the  use  of  architecture 
description  artifacts  mandated  by  accepted  archi¬ 
tecture  frameworks.  The  following  discussion  ad¬ 
dresses  the  importance  of  these  considerations  in 
creation  of  the  MDA  Enterprise  Architecture. 

Service-Oriented  Architecture 

It  is  important  to  separate  the  issues  of  service- 
oriented  architecture  from  service-oriented  imple¬ 
mentation  and  the  use  of  associated  technologies. 
SOA  focuses  on  how  to  design  the  provisioning  of 
automated  capabilities  and  the  interaction  of  ar¬ 
chitectural  entities  (i.e.  services)  that  provide  such 
capabilities.  Service-oriented  implementation  fo¬ 
cuses  on  the  design  of  technical  solutions  that  im¬ 
plement  automated  functions  to  achieve  a  service- 
oriented  architecture.  The  four  models  described 
above  will  focus  on  SOA,  but  an  effective  MDA 
information  sharing  solution  will  also  require  eval¬ 
uation  and  development  of  technology  for  service- 
oriented  implementation. 

The  Technology  Focus  Team  will  explore  exist- 
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ing  infrastructure  available  to  the  GMCOI  in  search 
of  capabilities  to  satisfy  the  emerging  infrastruc¬ 
ture  service  requirements  described  in  the  services 
and  information  exchange  models.  The  team  will 
identify  capability  gaps,  plan  for  solutions,  and  de¬ 
velop  a  solution  architecture  that  identifies  the  use 
of  existing  and  needed  technologies  to  achieve  the 
MDA  enterprise  architecture. 

From  a  SOA  point  of  view,  this  would  include 
evaluation  of  enterprise  service  infrastructures  and 
catalogs  of  available  services  resident  in  registries 
and  repositories  distributed  throughout  the  GM¬ 
COI.  It  is  important  that  the  capabilities  available 
via  the  MDA  information  pillars  adhere  to  the  in¬ 
teroperability  model  and  make  discoverable,  avail¬ 
able,  and  usable  their  current  and  future  informa¬ 
tion  services  to  satisfy  the  services  and  information 
exchange  models.  Evaluation  and  mapping  of  cur¬ 
rent  capabilities  within  the  GMCOI  will  result  in 
development  of  an  as-is  architecture  for  MDA  in¬ 
formation  sharing. 

Rather  than  architecting  and  constructing  new 
technical  solutions  to  achieve  a  to-be  MDA  enter¬ 
prise  architecture,  existing  capabilities  and  tech¬ 
nology  will  be  federated,  or  linked,  to  create  new 
capabilities.  Through  its  focus  teams,  the  Archi¬ 
tecture  Management  Hub  will  identify  existing 
architecture  federation  approaches,  recommend  a 
federation  strategy,  and  transition  legacy  technol¬ 
ogy  to  a  federated  approach  where  existing  capa¬ 
bilities  or  services  within  organizations  are  able  to 
interact. 

Numerous  efforts  are  ongoing  throughout  the 
Federal  Government  to  develop  core  enterprise  in¬ 
frastructure  and  services.  Core  services  common¬ 
ly  include  directory  and  search  capability,  identity 
management  services  and  attribute  stores,  security 
services,  mediation,  messaging,  and  collaboration. 


Exposing,  leveraging,  and  aligning  these  ser¬ 
vices  will  be  critical  to  the  MDA  enterprise  archi¬ 
tecture.  The  challenge  to  the  Architecture  Manage¬ 
ment  Hub  will  be  to  federate  these  infrastructures  to 
facilitate  net-centric  information  sharing  between 
federal  departments  and  agencies,  state,  local,  and 
tribal  governments,  international  partners  and  the 
private  sector.  Although  some  work  has  been  done 
in  the  field  of  federated  services,  most  notably  by 
the  Information  Sharing  Environment,  this  is  ba¬ 
sically  a  new  business  model.  Federating  service 
infrastructures  will  require  the  federation  of  core 
services  where  possible.  For  example,  rather  than 
develop  an  MDA  metadata  registry  and  repository, 
metadata  registries  from  the  various  service  infra¬ 
structures  could  be  federated,  thus  allowing  them 
to  exchange  information  directly. 

The  challenge  for  the  Architecture  Manage¬ 
ment  Hub  will  be  to  develop  a  repeatable  process 
to  federate  services  and  infrastructures.  The  Ar¬ 
chitecture  Management  Hub  will  then  need  to  edu¬ 
cate  members  of  the  GMCOI  on  how  to  implement 
these  processes.  This  can  be  done  in  an  iterative 
approach  in  which  users  are  continually  trained  as 
they  are  added  to  the  network. 

Because  many  federal  departments  and  agen¬ 
cies  do  not  yet  operate  in  a  net-centric  SOA  envi¬ 
ronment,  an  additional  challenge  for  the  Architec¬ 
ture  Management  Hub  will  be  the  need  to  provide 
methods  for  those  agencies  to  publish  and  subscribe 
data  and  services  to  and  from  the  network. 

There  will  likely  be  some  core  services  for 
which  federation  is  not  an  optimal  solution.  Selec¬ 
tion  of  an  individual  agency  to  provide  these  ser¬ 
vices  to  the  GMCOI  may  be  required.  For  instance, 
it  may  be  necessary  to  select  an  “implementation 
agent”  for  some  collaboration  services  to  support  a 
common  operational  picture  across  MDA. 

Architecture  Frameworks  and  Descriptions 

Once  completed,  the  MDA  enterprise  architec¬ 
ture  must  be  presented  in  a  form  commonly  used 
by  and  understandable  to  decision-makers,  review¬ 
ers,  and  architects  of  other  efforts.  This  is  usually 
accomplished  through  the  use  of  an  architecture 
framework  -  a  framework  for  describing  and  com¬ 
municating  architectures.  Such  a  framework  is  a 
set  of  assumptions,  concepts,  values,  and  practices 
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that  constitutes  a  way  of  viewing  an  architecture 
reality.  An  architecture  framework  provides  a  col¬ 
lection  of  patterns  for  creating  and  presenting  ar¬ 
chitecture  descriptions. 

There  are  three  architecture  frameworks  of  in¬ 
terest  in  the  development  of  the  MDA  enterprise 
architecture:  the  Federal  Enterprise  Architecture 
(FEA);  the  DoD  Architecture  Framework  (DoDAF); 
and  the  Information  Sharing  Environment  Enter¬ 
prise  Architecture  Framework  (ISE  EAF). 

Most  non-DoD  federal  agencies  employ  the 
FEA  and  its  recent  extension,  the  Federal  Segment 
Architecture  Methodology  (FSAM).  FEA  em¬ 
phasizes  the  use  of  architectural  element  taxono¬ 
mies  expressed  as  references  models  (e.g.  Business 
Reference  Model,  Data  Reference  Model,  Service 
Component  Reference  Model,  etc.).  To  ensure 
maximum  interagency  application,  the  Architec¬ 
ture  Management  Hub  will  utilize  the  Federal  En¬ 
terprise  Architecture  in  describing  the  MDA  enter¬ 
prise  architecture. 

DoD  commands,  services,  and  agencies,  as  well 
as  the  Coast  Guard,  employ  the  DoDAF.  DoDAF 
emphasizes  the  use  of  a  variety  of  architectural 
models  to  describe  differing  perspectives  or  views 
of  a  whole  architecture.  DoDAF  provides  a  formal 
nomenclature  for  such  models.  Embedded  with¬ 
in  the  FEA  is  the  idea  of  using  models  to  express 
architectural  elements  and  their  relationships.  Al¬ 
though  FEA  and  DoDAF  use  similar  models,  FEA 
does  not  specify  a  model  nomenclature. 

The  challenge  to  the  Architecture  Management 


Hub  will  be  to  integrate  the  use  of  models  common 
to  both  FEA  and  DoDAF  within  the  higher-order 
structure  of  the  FEA’s  taxonomies  to  create  an  ac¬ 
tionable  architecture  description  for  the  MDA  en¬ 
terprise  architecture. 

While  the  FEA  and  the  DODAF  are  compliance 
frameworks,  the  ISE  EAF  is  not  vested  in  policy  as 
required  for  compliance.  Rather,  the  ISE  EAF  pro¬ 
vides  constructs,  or  patterns,  for  sharing  informa¬ 
tion  at  the  federal  level. 

The  Information  Sharing  Initiative  ISE  EAF 
was  developed  by  the  PM-ISE.  The  ISE  and  the  in¬ 
formation  resources  construct  developed  from  the 
ISE  EAF,  will  link  ISE  participants  (federal,  state, 
local  and  tribal  governments,  foreign  partners  and 
allies,  and  the  private  sector)  to  create  a  distributed, 
protected,  and  trusted  environment  for  sharing  in¬ 
formation.  The  ISE  EAF  will  evolve  over  time  as 
additional  business  processes,  information  flows 
and  exchanges,  services,  and  technologies  are  de¬ 
fined  and  incorporated  into  the  ISE.  While  the 
ISE  EAF  was  developed  for  primary  use  as  a  tool 
for  anti-terrorism,  its  constructs  can  be  used  to  en¬ 
able  general  information  sharing  within  the  Federal 
Government. 
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Vision  for  Net-Centric  Data  and  Services 
Sharing 

Establishing  a  shared  vision  for  net- 
centric  data  and  services  sharing  compels  a  shift 
from  point-to-point  interfaces  to  a  many-to-many 
exchange  of  data,  and  enables  many  users  and  ap¬ 
plications  to  leverage  the  same  data  and  services. 
A  key  objective  is  to  accelerate  decision  cycles  by 
ensuring  that  the  right  data  is  available  at  the  right 
time,  in  the  right  place. 

Making  data  visible,  accessible,  understand¬ 
able,  and  trustable  are  the  cornerstones  of  net-cen¬ 
tric  information  sharing.  The  creation  of  duplica¬ 
tive  data  and  redundant  capabilities  often  results 
from  consumers’  inability  to  locate,  access,  or 
understand  existing  data  assets,  or  trust  that  they 
meet  their  needs. 

The  purpose  of  establishing  data  standards  is  to 
facilitate  agile  information  sharing  across  the  MDA 
community  of  data  producers  and  data  consumers. 

The  National  MDA  Architecture  Management 
Hub’s  approach  to  data  standards  is  to  leverage  ex¬ 
isting  data  sharing  initiatives,  best  practices,  and 
lessons  learned;  identify  information  exchanges; 
identify  authoritative  sources  of  data  as  necessary; 
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define  data  quality  of  service  standards;  and  recom¬ 
mend  common  vocabulary,  information  exchange, 
and  registration  processes  and  tools.  The  goal  of 
this  approach  is  to  provide  seamless  interoper¬ 
ability  across  the  MDA  community  that  will  pro¬ 
vide  a  secure,  collaborative,  information-sharing 
environment. 

Reference  Data  and  Services  Synchronization 

The  MDA  as-is  data  architecture  will  describe 
existing  maritime  data  sources,  producers,  consum¬ 
ers,  and  existing  information  exchanges  as  a  base¬ 
line  for  moving  forward.  Identifying  existing  data 
sharing  initiatives,  best  practices,  lessons  learned, 
and  information  exchanges  are  critical  early  steps 
to  creating  the  baseline.  This  baseline  will  assist  in 
identifying  data  assets  that  are  authoritative  sourc¬ 
es  for  data,  as  well  as  identifying  the  contexts  in 
which  the  data  is  authoritative.  In  situations  where 
there  is  more  than  one  authoritative  source,  depend¬ 
ing  on  how  the  data  is  used,  services  are  needed  to 
indicate  the  business  process  for  which  the  author¬ 
ity  is  valid.  Stewardship  of  data  sources  will  be 
considered  when  determining  authoritativeness. 

A  web-accessible  registry  will  be  needed  to 
capture  and  manage  data  sources,  producers,  and 
consumers.  As  data  producers  register  their  data 
assets  in  the  registry,  the  registry  can  be  used  to 
identify  authoritative  sources  of  data  as  necessary, 
reduce  and  eliminate  duplicative  data  as  appropri¬ 
ate,  identify  data  gaps  and  incompatibilities,  and 
align  data  naming,  design,  and  information  ex¬ 
change  standards. 

Data  Quality 

Data  assets  can  be  trusted  only  if  their  con¬ 
tents  are  sufficiently  accurate  and  of  sufficiently 
reliable  quality.  Quality  assertions  about  data  in¬ 
clude  information  on  its  accuracy,  completeness,  or 
timeliness  for  a  particular  purpose.  For  example, 
consumers  might  need  to  know  the  age  of  the  data 
to  determine  whether  it  is  still  applicable,  or  they 
might  need  to  know  how  accurate  estimates  and 
figures  within  the  data  asset  are.  Assessing  and  im- 
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proving  data  asset  quality  is  important.  Quality  of 
service  standards  and  active  stewardship  need  to 
be  defined  and  coordinated  to  establish  and  main¬ 
tain  the  quality  and  relevance  of  authoritative  data 
sources. 

The  Architecture  Management  Hub  will:  de¬ 
velop  an  ongoing  process  for  the  enterprise  hubs  to 
audit  the  quality  of  data  assets  that  are  made  visible 
and  accessible;  develop  guidelines  for  data  produc¬ 
ers  and  consumers  to  ensure  that  the  data  required 
by  the  GMCOI  is  available,  accurate,  complete,  and 
interoperable;  provide  a  single  joint  collaborative 
forum  for  coordination  of  MDA  data  architecture, 
data  quality,  and  metadata;  and  provide  a  single 
means  to  address,  resolve,  and  track  data  issues. 

Standard  Vocabulary  Methodology 

MDA  data  and  services  producers  and  con¬ 
sumers  comprise  a  collaborative  group  of  users 
who  must  exchange  information  in  pursuit  of  their 
shared  goals,  interests,  missions,  or  business  pro¬ 
cesses.  To  facilitate  this  information  exchange,  the 
MDA  users  need  a  shared  vocabulary  for  the  in¬ 
formation  they  exchange.  The  Architecture  Man¬ 
agement  Hub  will  work  with  the  Cargo,  Vessel, 
People,  and  Infrastructure  hubs  to  create  necessary 
data  standards  and  a  shared  vocabulary  to  facilitate 
exchange  of  the  information  within  and  among  the 
hubs. 

The  National  Information  Exchange  Model 
(NIEM),  Universal  Core  (UCore),  and  Maritime 
Information  Exchange  Model  (MIEM)  are  refer¬ 
ence  models  designed  to  enable  a  level  of  interop¬ 
erability  in  the  exchange  of  information — for  the 
sender  and  receiver  of  information  to  share  a  com¬ 
mon,  unambiguous  understanding  of  the  meaning 
of  that  information.  Each  of  these  reference  mod¬ 
els  started  independently  but  they  are  now  aligning 
as  complementary  initiatives  with  complementary 
models. 

The  NIEM  “is  designed  to  develop,  dissemi¬ 
nate,  and  support  enterprise-wide  information  shar¬ 
ing  standards  and  processes  across  the  whole  of  the 
justice,  public  safety,  emergency  and  disaster  man¬ 
agement,  intelligence,  and  homeland  security  en¬ 
terprise  at  all  levels  and  across  all  branches  of  gov¬ 
ernment”  (reference  (m)).  The  NIEM  represents  a 
collaborative  partnership  of  agencies  and  organiza¬ 


tions  across  all  levels  of  government  (federal,  state, 
tribal,  and  local)  and  with  the  private  sector. 

The  NIEM  reference  model  includes  two  cat¬ 
egories  of  reusable  components:  core  components 
and  community-specific  components.  The  NI- 
EM’s  core  components  are  further  classified  as  ei¬ 
ther  universal  or  common.  Community-specific 
components  are  organized  around  functional  lines 
of  business,  such  as  the  maritime  community,  and 
are  understood  and  managed  by  a  specific  commu¬ 
nity  of  interest,  such  as  the  GMCOI.  Community- 
specific  components  can  extend  core  components 
and  must  conform  to  the  NIEM  naming  and  design 
rules.  Community  specific  components  are  orga¬ 
nized  to  facilitate  governance,  and  each  has  some 
measure  of  persistency.  Communities  traditionally 
include  a  cohesive  group  of  data  stewards  who  are 
subject  matter  experts  (SMEs),  have  some  level  of 
authority  within  the  communities  they  represent, 
and  participate  in  the  processes  related  to  harmo¬ 
nizing  conflicts  and  resolving  data  component 
ambiguities. 

MIEM  development  began  in  2006  to  support 
collaborative  tracking  of  vessels,  people,  and  cargo. 
Also  beginning  in  2006,  but  as  a  separate  initiative, 
the  MDA  DS  COI  was  formed  to  define  schemas 
for  sharing  sensor  data,  such  as  data  received  from 
Automatic  Identification  System  (AIS)  transpon¬ 
ders.  The  MDA  DS  COI  became  a  beta  tester  of  the 
MIEM  and  has  demonstrated  successful  modeling 
and  sharing  of  that  data.  The  approach  for  MDA 
data  standards  at  the  national  level  is  to  establish 
MIEM  as  the 
maritime  com¬ 
munity  exten¬ 
sion  of  NIEM. 

UCore  is  an 
interagency  ini¬ 
tiative  accom¬ 
plishing  a  criti¬ 
cal  functional 
element  of  the 
National  Infor¬ 
mation  Sharing 
Strategy-estab¬ 
lishing  an  infor¬ 
mation  exchange 
specification  and 
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Universal 
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implementation  profile.  This  consists  of  a  vocabu¬ 
lary  of  most  commonly  exchanged  concepts,  XML 
representation  of  the  concepts,  extension  rules  to 
allow  tailoring  to  specific  mission  areas,  security 
marking  to  permit  controlled  access,  and  a  mes¬ 
saging  framework  to  package  and  unpackage  the 
content  consistently.  UCore  Version  2.0  defines  a 
small  number  of  universally  understandable  con¬ 
cepts  that  are  commonly  shared  and  understood 
among  all  participating  communities.  Development 
of  Version  2.0,  has  extended  beyond  the  “Where” 
and  “When”  of  Version  1.0  to  include  the  “Who” 
and  “What”  components.  During  the  alpha-testing 
phase,  the  UCore  development  team  created  and 
published  an  information  exchange  specification 
and  coordinated  approximately  20  risk  reduction 
pilots  conducted  by  various  organizations  in  the 
DoD,  Department  of  Homeland  Security  (DHS), 
Director  of  National  Intelligence  (DNI),  and  De¬ 
partment  of  Justice  (DOJ). 

The  NIEM  program  has  committed  to  ensur¬ 
ing  that  future  versions  of  NIEM  will  be  compat¬ 
ible  with  UCore.  UCore  has  been  designed  to  be 
interoperable  with  NIEM  so  that  current  NIEM- 
based  systems  can  share  information  via  UCore. 

The  MDA  vocabulary  will  be  an  integration 
of  MIEM,  as  the  maritime  community’s  extension 
to  NIEM,  and  UCore  products  and  services.  This 
methodology  will  provide  common  processes  and 
guidelines  for  metadata  naming  and  design  rules, 
extending  the  MDA  core  vocabulary,  and  register¬ 
ing  metadata  assets. 

Standard  Data  Exchange  Methodology 

Current  data  exchange  initiatives  and  meth¬ 
odologies  employed  by  stakeholder  organizations 
within  and  across  the  MDA  community  have  cre¬ 
ated  a  web  of  terminology  and  data  models  that 
may  not  be  interoperable.  The  standardized  data 
exchange  methodology  for  MDA  must  build  upon 
and  extend  established  methodologies,  processes, 
and  tools  from  MIEM,  NIEM,  and  UCore  success¬ 
es.  Recognizing  the  importance  of  using  common 
information  elements,  the  interagency  community 
has  begun  to  define  a  UCore  model.  While  this 
model  attempts  to  address  the  interoperability  is¬ 
sue,  it  is  necessary  to  ensure  that  this  approach 
aligns  with  other  efforts  within  and  across  the  mar¬ 


itime  community. 

Success  of  the  MDA  mission  relies  on  data  ex¬ 
change  capabilities  that  are  available,  reliable,  se¬ 
cure,  and  easy  to  find  and  use.  Support  mecha¬ 
nisms  need  to  be  in  place  to  help  users  discover  and 
access  authoritative  sources  of  data,  understand 
the  data,  and  select  the  items  they  need.  Capabili¬ 
ties  and  resources  need  to  be  in  place  to  support 
data  and  information  sharing  operations  to  include 
the  tracking,  reporting,  and  management  of  in¬ 
formation  exchange  services  and  their  associated 
infrastructure. 

The  standardized  data  exchange  methodology 
must  provide  common  processes  and  guidelines, 
and  a  consistent  set  of  tools  and  services  to  enable 
the  discovery  of  information  across  security  and 
organizational  communities,  as  well  as  to  support 
the  tagging  and  marking  of  data  and  services.  The 
goals  of  this  approach  are  to  identify  best  practic¬ 
es  for  establishing  standards  for  these  basic  core 
elements,  increase  the  unity  of  effort  at  the  stra¬ 
tegic  level,  define  cross-organizational  standards 
for  information  exchange,  recommend  needed  gov¬ 
ernance  and  support,  and  define  common  widely- 
accessible  tools  to  support  information  exchange 
standards. 
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nformation  Assurance  is  a  major  area  of  focus 
for  the  MDA  Architecture  Management  Hub. 
An  acceptable  level  of  trust  is  critical  in  en¬ 
abling  an  information  sharing  environment  involv¬ 
ing  multiple  federal,  state,  tribal,  and  other  sover¬ 
eign  nation  organizations.  However,  the  first  step  is 
agreeing  to  standards  that  all  participating  organi¬ 
zations  consider  trustworthy  from  an  information 
assurance  standpoint;  i.e.,  the  information  systems 
can  be  trusted  with  the  appropriate  safeguards  and 
countermeasures  necessary  to  operate  within  de¬ 
fined  levels  of  risk  to  organizational  operations  and 
assets,  individuals,  or  other  organizations,  despite 
the  possible  environmental  disruptions,  human  er¬ 
rors,  and  purposeful  attacks  that  may  occur.  To 
achieve  this  level  of  trust,  the  IA  processes  within 
this  net-centric  environment  must  ensure  a  mutu¬ 
ally  agreed  upon  acceptable  level  of  confidential¬ 
ity,  integrity,  availability,  and  authentication  of  the 
information  available.  Therefore,  the  foundation  of 
the  MDA  environment  must  have: 

•  The  ability  to  securely  exchange  information, 
including  classified  and  sensitive  information, 
as  well  as  intelligence  and  law  enforcement  sen¬ 
sitive  data,  across  multiple  security  domains. 

•  An  identity  management  solution  that  is  shared, 
standards-based,  and  recognized  and  accepted 
by  all  MDA  participants. 

•  Improved  and  standard  security  practices  across 
the  MDA  environment. 

•  A  risk  management  framework  to  ensure  that 
information  assurance  security  risks  are  ad¬ 
dressed  appropriately. 

Cross-Domain  and  Multi-Level  Security  Solu¬ 
tions 

There  will  be  users  within  the  MDA  environ¬ 
ment  who  may  not  have  a  security  clearance  but 
will  need  information  derived  from  sources  that 
may  be  highly  classified  and  compartmentalized. 
Such  information  must  first  be  sanitized  and  then 
must  be  able  to  move  throughout  the  MDA  envi¬ 
ronment.  Likewise,  personnel  working  on  a  classi¬ 
fied  network  need  to  be  able  to  access  unclassified 


information  in  order  to  form  a  complete  operating 
picture.  Safely  providing  access  to  multiple  levels  of 
information  and  moving  information  between  clas¬ 
sification  levels  or  organizational  domains  will  re¬ 
quire  trusted  solutions.  The  current  Cross  Domain 
Baseline  for  Distribution  produced  by  the  Unified 
Cross  Domain  Management  Office  (UCDMO)  will 
be  leveraged  to  achieve  this  requirement. 

Identity  Management  Solution 

Identity  management  provides  the  foundation 
that  enables  implementation  of  a  need-to-share 
information  paradigm;  it  is  a  critical  enabler  for 
the  control  of  access  to  resources  in  a  fashion  that 
balances  mission  need  with  risk  to  resources.  The 
Identity  Management  solution  must  enable  feder¬ 
ated  services.  There  are  three  key  components  to 
such  a  solution:  Identity  Proofing  when  credentials 
are  issued,  Identity  and  Credential  Authentication 
when  the  credentials  are  used,  and  Access  Control 
to  limit  the  user  to  appropriate  access  and  actions. 

Identity  Proofing.  Identity  proofing  is  the  key¬ 
stone  to  the  credibility,  reliability,  and  accuracy  of 
the  overall  identity  management  process,  so  that 
resultant  credentials  are  bound  directly  to  the  actu¬ 
al  identity  of  the  individual  requesting  them  when 
they  are  issued.  The  identity  management  solution 
must  be  able  to  support  multiple  requirements  for 
identity  proofing  (e.g.,  man-to-man,  man-to-ma- 
chine,  and  machine-to-machine  processes). 

Identity  and  Credential  Authentication.  When 
an  individual  asserts  an  identity  claim  when  ac¬ 
cessing  systems  or  services,  an  identity  manage¬ 
ment  service  must  authenticate  that  claim  through 
the  use  of  the  credential  issued  to  the  individual.  To 
achieve  that  goal,  the  credential  must  be  authenti¬ 
cated.  Credential  authentication  is  a  service  that  al¬ 
lows  any  entity  in  the  enterprise  to  determine  that 
a  trusted  credential  has  not  been  forged,  has  not 
expired,  and  has  not  been  revoked  or  suspended. 
The  authentication  service  must  support  scalable 
operations  that  remain  accessible  and  robust  in  the 
face  of  cyber  attacks.  In  implementing  identity  and 
credential  authentication,  we  will  draw  upon  the 
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lessons  learned  from  ongoing  efforts. 

Access  Control  (Authorization).  Critical  in  a 
net-centric  cross-agency  environment  is  access 
control-determining  when  a  user  is  authorized  to 
access  information,  systems,  or  services.  All  MDA 
users  require  immediate  on-demand  access  to  the 
range  of  products  and  services  available  within 
the  MDA  environment,  regardless  of  the  orga¬ 
nization  in  which  the  product  or  service  actually 
resides.  Therefore  the  MDA  data  sharing  environ¬ 
ment  must  provide  support  for  the  unanticipated 
user-one  not  previously  registered  or  enrolled  with 
the  organization  providing  services.  An  emerging 
means  of  providing  this  support  in  a  net-centric  en¬ 
vironment  is  through  Attribute-Based  Access  Con¬ 
trol  (ABAC).  This  approach  allows  decisions  con¬ 
cerning  access  to  information  to  be  made  based  on 
organizational  and  enterprise  attributes  of  the  new 
user,  rather  than  on  prepared  classification  and  per¬ 
mission  assignments.  ABAC  in  an  interagency  en¬ 
vironment  needs  to  be  supported  by  robust  and  re¬ 
liable  identity  management  and  attribute  services. 
The  federated  identity  management  service  must 
provide  mutually  trusted  authentication  of  identi¬ 
ty  claims  using  credentials  presented  by  the  unan¬ 
ticipated  user;  the  federated  attribute  management 
service  must  provide  accurate  attributes  bound  to 
an  authenticated  identity  at  the  enterprise  and  local 
levels.  This  solution  must  consider  not  only  the  at¬ 
tributes  currently  available,  but  also  the  attributes 
that  may  be  needed  in  the  future.  We  will  draw  ex¬ 
tensively  on  the  lessons  learned  from  the  ABAC 
pilot  that  the  MDA  Data  Sharing  COI  is  currently 
conducting,  and  several  other  pilots  being  conduct¬ 
ed  throughout  the  DoD.  We  will  also  leverage  work 
done  by  the  Intelligence  Community  (IC)  DoD  At¬ 
tributes  and  Authorization  Tiger  Team  to  provide  a 
starting  point  for  a  CONOPS  and  standards. 

Improved  and  Standard  Security  Practices 
across  the  MDA  Environment 

To  share  information  among  different  organi¬ 
zations,  there  must  be  mutual  trust  in  all  participat¬ 
ing  organizations’  information  systems.  To  achieve 
this  trust,  all  information  systems  must  be  certi¬ 
fied,  accredited,  and  maintained  to  an  agreed  upon 
set  of  standards.  The  standards  for  acceptable  risk 
must  be  common  across  all  participating  organiza¬ 


tions.  Likewise,  the  risk  determination  by  one  or¬ 
ganization  for  its  data  must  be  acceptable  by  any 
other  organization  whose  data  may  reside  on  that 
organization’s  information  systems. 

Common  Set  of  Standards  for  Certification  and 
Accreditation  (C&A)  Activities.  A  common  set  of 
C&A  standards  and  adherence  to  those  standards 
are  critical  because  these  are  the  basis  upon  which 
trust  in  other  organizations’  information  systems 
is  established,  thus  allowing  unfettered  informa¬ 
tion  access.  This  is  especially  true  and  critical  if 
any  participating  organization  uses  an  information 
system  that  will  operate  at  a  multi-level  security 
(MLS)  mode.  The  C&A  Transformation  Initia¬ 
tive,  a  joint  DoD  and  DNI  CIO  effort  to  drastically 
streamline  the  C&A  process  for  national  security 
systems,  and  National  Institute  of  Standards  and 
Technology  (NIST)  Recommended  Security  Con¬ 
trols  for  Federal  Information  Systems  (SP800-53), 
will  be  leveraged  to  achieve  this  requirement. 

C&A  Reciprocity.  In  a  net-centric  information¬ 
sharing  environment,  reciprocity  for  C&A  activi¬ 
ties  across  all  participating  organizations  is  criti¬ 
cal.  Once  a  common  set  of  security  standards  is 
accepted  by  the  participating  organizations,  the 
first  step  is  reciprocity  of  the  certifications  with  the 
ultimate  goal  of  having  reciprocity  for  both  certifi¬ 
cations  and  accreditations.  Again,  a  joint  DoD  and 
DNI  CIO  effort  to  drastically  streamline  the  C&A 
process  for  national  security  systems  will  be  lever¬ 
aged  to  achieve  this  requirement. 

Controlled  Unclassified  Information  (CUI). 
Since  it  is  likely  that  much  of  the  information  in 
the  MDA  environment  will  qualify  as  CUI  as  de¬ 
fined  by  reference  (1),  it  is  necessary  that  partici¬ 
pating  organizations  control  and  mark  any  CUI  as 
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required  by  reference  (1),  so  that  it  will  be  handled 
appropriately. 

Risk  Management  Framework 

The  risk  associated  with  information  sharing 
among  MDA  participants  must  be  continuously 
mitigated  by  employing  a  Risk  Management  Frame¬ 
work  (RMF).  The  RMF  provides  GMCOI  members 
with  a  disciplined,  structured,  flexible,  extensible, 
and  repeatable  process  for  achieving  agreed-upon 
degrees  of  trustworthiness  for  MDA  information 
systems.  The  RMF,  which  operates  within  the  con¬ 
text  of  the  architecture  development  life  cycle,  can 
be  applied  to  both  new  and  legacy  information  sys¬ 
tems  that  are  part  of  the  MDA  environment.  The 
RMF  leverages  well-defined  information  security 
standards  and  guidelines  to  facilitate  the  sharing  of 
information  and  demonstrate  compliance  with  the 
information  security  requirements.  The  plug-and- 
play  nature  of  the  RMF  allows  any  potential  MDA 
participant,  e.g.,  federal,  state,  local,  and  tribal  gov¬ 


ernments,  private  sector  and  international  partners 
to  use  the  framework.  The  RMF  being  developed 
by  PM-ISE  along  with  RMF  initiatives  being  de¬ 
veloped  by  NIST,  CNSS  and  the  IC  will  be  lever¬ 
aged  to  develop  the  MDA  RMF. 

The  MDA  RMF: 

•  Embodies  the  basic  principles  of  information 
security  -  confidentiality,  integrity,  and  avail¬ 
ability  -  so  that  MDA  participating  organiza¬ 
tions  are  assured  that  the  information  they  pro¬ 
vide  will  be  protected  adequately. 

•  Is  integrated  with  the  MDA  Enterprise 
Architecture. 

•  Employs  appropriate  information  security  stan¬ 
dards  and  guidance. 

•  The  MDA  RMF  consists  of  the  following  steps, 
as  illustrated  by  the  figure  below,  with  the  NIST 
security  standards  and  guidelines  associated 
with  each  activity  for  risk  management. 

Step  1.  Categorize  the  MDA  information  sys¬ 
tems  and  information  residing  within  the  systems 
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based  on  the  security  category  recommendations 
from  the  appropriate  Information  Security  gover¬ 
nance  functions.  This  categorization  must  consider 
the  potential  impact  of  limiting  access  to  the  infor¬ 
mation,  as  well  as  potential  impacts  if  the  informa¬ 
tion  is  shared.  The  business  context  that  consists  of 
the  applicable  laws,  directives,  and  policy  guide¬ 
lines  as  well  as  MDA  strategic  goals,  objectives, 
and  priorities  must  also  be  considered.  The  risks 
associated  with  each  category  must  be  identified 
and  prioritized. 

Step  2.  Select,  supplement,  and  document 
safeguards  and  countermeasures. 

•  Select  an  agreed  upon  set  of  safeguards  and 
countermeasures  for  MDA  information  sys¬ 
tems  based  on  the  prioritized  technical  risks, 
security  categorizations,  and  recommendations 
from  the  MDA  security  governance  functions. 

•  Supplement  the  agreed  upon  set  of  safeguards 
and  countermeasures  based  on  an  assessment 
of  the  MDA  participant’s  site  specific  risk  con¬ 
ditions,  including  organizational-specific  secu¬ 
rity  requirements,  specific  and  credible  threat 
information,  cost-benefit  analyses,  and  special 
circumstances. 

•  Document  the  set  of  safeguards  and  counter¬ 
measures  in  the  MDA  information  system  se¬ 
curity  plan,  including  the  rationale  for  any  re¬ 
finements  and  adjustments  to  the  implemented 
set  of  safeguards  and  countermeasures  based 


on  MDA  participants’  site-specific  conditions. 

Step  3.  Implement  the  set  of  safeguards 
and  countermeasures  in  the  MDA  information 
systems. 

Step  4.  Assess  the  safeguards  and  countermea¬ 
sures  using  appropriate  methods  to  determine  the 
extent  to  which  they  are  implemented  correctly,  op¬ 
erate  as  intended,  and  produce  the  desired  outcome 
with  respect  to  meeting  the  security  requirements 
of  the  MDA  information  system.  This  step  is  key 
to  demonstrating  the  degree  of  trustworthiness  of 
the  system,  a  critical  input  to  the  risk  decision  and 
maintenance  of  trust  within  the  MDA  environment. 
The  assessment  will  be  documented  in  the  Security 
Assessment  Report. 

Step  5.  Authorize  the  information  system  op¬ 
eration  with  the  implemented  safeguards  and  coun¬ 
termeasures  based  upon  a  determination  that  the 
risk  to  MDA  participants’  operations  and  assets,  is 
acceptable.  This  step  results  in  an  Authority  to  Op¬ 
erate  (ATO)  for  this  particular  MDA  information 
system. 

Step  6.  Monitor  and  assess  the  documented 
and  agreed  upon  set  of  safeguards  and  countermea¬ 
sures  in  all  MDA  information  systems  on  a  con¬ 
tinual  basis.  Document  any  changes  to  information 
systems,  conduct  security  impact  analyses  of  the 
associated  changes,  and  report  the  security  status 
of  the  information  systems  to  appropriate  MDA  of¬ 
ficials  on  a  regular  basis. 
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Resource  Strategy 
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Resources  dedicated  to  accomplishing  the 
goal  of  a  net-centric,  information  sharing 
environment  as  outlined  in  this  document, 
will  be  applied  toward  two  complementary  efforts. 
First,  resources  are  needed  to  design  and  develop 
the  MDA  enterprise  architecture.  Second,  depart¬ 
ments  and  agencies,  guided  by  the  architecture, 
will  invest  resources  in  a  manner  that  will  increase 
information  sharing  and  lead  to  greater  levels  of 
MDA. 

Designing  an  effective  architecture  to  be  uti¬ 
lized  by  the  entire  GMCOI  will  require  an  invest¬ 
ment  of  time  and  expertise.  To  be  successful, 
members  of  the  GMCOI  must  be  willing  to  con¬ 
tribute  knowledgeable  individuals  to  participate 
in  the  MDA  Architecture  Management  Hub  focus 
teams.  These  focus  teams  will  set  priorities  and 
develop  the  standards  and  processes  that  will  lead 
to  a  federated  information  sharing  environment. 


As  the  architecture  is  designed,  budget  authori¬ 
ties  will  gain  a  better  understanding  of  the  magni¬ 
tude  of  the  resource  requirements  necessary  to  im¬ 
plement  capabilities  to  support  MDA.  The  MDA 
enterprise  architecture  will  act  as  guidance  for  in¬ 
vestments  which  can  contribute  to  MDA,  and  assist 
departments  and  agencies  in  their  efforts  to  address 
the  capability  gaps  highlighted  in  the  Interagency 
Investment  Strategy.  The  architecture  will  focus 
those  efforts,  help  ensure  interoperability,  and  pre¬ 
vent  unnecessary  redundancy.  As  segments  of  the 
MDA  enterprise  architecture  are  designed,  mem¬ 
bers  of  the  GMCOI  can  use  the  standards  and  pro¬ 
cesses  developed  to  inform  their  acquisition  plans. 
Design  of  the  architecture  will  leverage  existing 
and  emergent  infrastructure,  systems,  services, 
and  other  initiatives.  Therefore,  much  of  the  cost 
will  be  borne  by  those  efforts. 
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Summary 


As  the  lead  for  the  MDA  Architecture  Man¬ 
agement  Hub,  the  DON  CIO  will  follow 
the  approach  outlined  in  this  document  to 
design  an  actionable  MDA  enterprise  architecture 
that  can  guide  implementation  efforts  to  achieve  a 
secure,  collaborative  information  sharing  environ¬ 
ment  for  the  GMCOI.  This  architecture  will  build 
on  the  work  of  other  organizations  and  draw  upon 
the  expertise  of  individuals  from  those  organiza¬ 
tions.  Working  within  the  governance  structure 
created  by  the  MDA  CONOPS,  the  Architecture 
Management  Hub  will  develop  a  set  of  complemen¬ 
tary  architectural  models.  These  models  will  con¬ 
stitute  the  core  of  an  as-is  and  to-be  MDA  Enter¬ 
prise  Architecture.  They  will  serve  as  the  basis  for 
development  of  an  architecture  mi¬ 
gration  and  implementation  plan. 

By  following  this  document’s 
approach  to  establishing  and  imple¬ 
menting  data  standards,  the  result¬ 
ing  architecture  will  provide  data 
and  information  exchange  stan¬ 
dards  that  permit  organizations  to 
publish  information  for  use  by  au¬ 
thorized  users.  The  MDA  Archi¬ 
tecture  Management  Hub  will  also 
recommend  standard  solutions  for 
sharing  information  across  security 
domains,  when  authorized  and  ap¬ 
propriate,  and  for  controlling  infor¬ 
mation  access. 

Implementation  of  this  plan  will 
follow  an  iterative  process,  begin¬ 
ning  with  agencies  and  departments 
within  the  Federal  Government  and 
adding  products  and  services  over 
time.  As  soon  as  this  process  is  in 
place  and  functioning,  representa¬ 
tive  organizations  from  state,  local, 
and  tribal  governments,  as  well  as 
appropriate  representatives  from 
the  private  sector  and  international 
organizations  will 

be  invited  to  participate.  The 


work  of  the  Architecture  Management  Hub  will 
benefit  all  members  of  the  GMCOI,  and  increased 
participation  will  have  exponential  rewards  for  all. 
Members  of  the  GMCOI  from  outside  the  Federal 
Government  must  be  involved  early  in  the  process 
to  promote  greater  efficiencies  and  minimize  the 
risk  of  incompatible  solutions. 

The  work  of  the  MDA  Architecture  Manage¬ 
ment  Hub  will  extend  well  beyond  the  GMCOI. 
The  information  sharing  standards  and  methods 
developed  for  MDA  will  have  application  through¬ 
out  the  Federal  Government  and  beyond.  The  pro¬ 
cesses  and  methodologies  developed  by  this  effort 
can  benefit  COIs  and  organizations  facing  similar 
information  challenges. 
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Guidance  for  MDA  information  sharing  is  de¬ 
rived  from  the  following  documents: 


A. 


B. 


C. 

D. 

E. 

F. 

G. 

H. 

I. 

J. 

K. 


L. 


M. 


N. 

O. 

P. 

Q. 

R. 


National  Plan  to  Achieve  Maritime  Domain  Aware¬ 
ness  for  the  National  Strategy  for  Maritime  Secu¬ 
rity,  October  2005 

Global  Maritime  Intelligence  Integration  Plan  for 
the  National  Strategy  for  Maritime  Security,  Octo¬ 
ber  2005 

National  Concept  of  Operations  for  Maritime  Do¬ 
main  Awareness,  December  2007 

National  Maritime  Domain  Awareness  Interagency 
Investment  Strategy,  May  2007 

MDA  Interagency  Requirements  Analysis  (IARA) 

National  MDA  Study  Inter-agency  Needs  Analysis 
(I ANA),  December  21,  2006 

MDA  Interagency  Capabilities  Document,  Version 
2.0.3,  31  January  2007  (IACD) 

MDA  Interagency  Core  Architecture  Document 
(IACA),  Draft  Version  1.2,  February  08,  2007 

National  Strategy  for  Information  Sharing,  October 
2007 

Information  Sharing  Environment  Enterprise  Archi¬ 
tecture  Framework,  v.2.0  September  2008 

Executive  Order  13388,  Further  Strengthening  the 
Sharing  of  Terrorism  Information  to  Protect  Ameri¬ 
cans,  October  25,  2005 

Presidential  Memorandum,  Subj:  Designation  and 
Sharing  of  Controlled  Unclassified  Information 
(CUI),  May  9,  2008 

NIEM  Program  Management  Office,  Introduction  to 
the  National  Information  Exchange  Model  (NIEM), 
version  0.3,  February  12,  2007  (available  at  http:// 
www.niem.gov/files/NIEM_lntroduction.pdf) 

United  States  Intelligence  Community  Information 
Sharing  Strategy,  February  22,  2008 

Department  of  Homeland  Security  Information 
Sharing  Strategy,  April  18  2008 

DoD  Directive  2005. 02E  Maritime  Domain  Aware¬ 
ness  (MDA)  in  the  Department  of  Defense 


(IA),  October  24,  2002 

S.  DoD  Net-Centric  Data  Strategy,  May  9,  2003 

T.  DoD  Directive  8320.02,  Data  Sharing  in  a  Net-Cen¬ 
tric  Department  of  Defense,  December  2,  2004. 

U.  FIPS  PUB  201-1:  Personal  Identity  Verification 
(PIV)  of  Federal  Employees  and  Contractors 

V.  National  Maritime  Intelligence  Center  (NMIC)  In¬ 
tegrated  Maritime  Intelligence  Architecture  (IMA) 
Transformation  Strategy,  Release  Version  1.1  ,01 
March  2007 
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DoD  Information  Sharing  Strategy,  May  4,  2007 
DoD  Directive  8500.01  E,  Information  Assurance 
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Acronym 

Full  Text 

ABAC 

Attribute  Based  Access  Control 

AIS 

Automatic  Identification  System 

C&A 

Certification  and  Accreditation 

CES 

Core  Enterprise  Services 

CBP 

Customs  and  Border  Protection 

COI 

Community  of  Interest 

CONOPS 

Concept  of  Operations 

CNSS 

Committee  on  National  Security  Systems 

CUI 

Controlled  Unclassified  Information 

DHS 

Department  of  Homeland  Security 

DNI 

Director  of  National  Intelligence 

DoD 

Department  of  Defense 

DoDAF 

DoD  Architecture  Framework 

DOJ 

Department  on  Justice 

DON 

Department  of  the  Navy 

DON  CIO 

Department  of  the  Navy  Chief  Information 
Officer 

DOT 

Department  of  Transportaion 

DS  COI 

Data  Sharing  Community  of  Interest 

FEA 

Federal  Enterprise  Architecture 

FSAM 

Federal  Segment  Architecture  Methodol¬ 
ogy 

GMAII 

Global  Maritime  and  Air  Intelligence 
Integration 

GMCOI 

Global  Maritime  Community  of  Interest 

Acronym  Full  Text 


GMSA  Global  Maritime  Situation  Awareness 


IA 

Information  Assurance 

IACA 

Interagency  Core  Architecture  Document 

1C 

Intelligence  Community 

IMA 

Integrated  Maritime  Intelligence  Architec¬ 
ture 

IOOS 

Integrated  Ocean  Observing  System 

ISE 

Information  Sharing  Environment 

ISE  EAF 

Information  Sharing  Environment  Enter¬ 
prise  Architecture  Framework 

ISSC 

Information  Sharing  Sub  Committee 

IT 

Information  Technology 

MDA 

Maritime  Domain  Awareness 

MIEM 

Maritime  Information  Exchange  Model 

MLS 

Multi  Level  Security 

NCES 

Net-Centric  Enterprise  Services 

NIEM 

National  Information  Exchange  Model 

NIST 

National  Institute  of  Standards  and  Tech¬ 
nology 

NOAA 

National  Oceanographic  and  Atmospheric 
Administration 

Pll 

Personally  Identifiable  Information 

SME 

Subject  Matter  Experts 

SOA 

Service  Oriented  Architecture 

Ucore 

Universal  Core 
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Change  History 


Version 

Publication  Date 

Description  of  Change 

1.0 

10/2008 

Initial  DON  CIO  Release 

1.1 

01/2009 

Incorporate  Interagency  Action  officer  Comments 

1.2 

01/2009 

Incorporated  Interagency  Flag/General  Officer  and  SES  Comments 
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